1. Field
The embodiments discussed herein are directed to a computer-readable recording medium storing a verification support program, verification support apparatus, and verification support method for supporting a verification of a system hardware design.
2. Description of the Related Art
Heretofore, when designing a new system using a semiconductor integrated circuit, a verification process estimating a power consumption and processing performance (a processing time until a desired operation is completed) of the whole system when causing the designed system to perform the desired operation may be needed at a stage before shifting to the manufacture of the actual device. In the verification process, the designer determines whether the design details are appropriate. Also, by the designer referring to a verification result and modifying the design details as necessary, a reduction of power consumption and improvement of processing performance is possible, and it is possible to respond to the needs of a user.
In the verification process, conventionally, for estimating the power consumption and processing performance of the whole system, generally, a simulation of a verification subject system operation, using a system model wherein a system which is a verification subject is realized by software, is known.
FIG. 1 illustrates a configuration example of a verification subject system. When simulating an operation of the verification subject system 10, it is necessary to prepare a system model of the verification subject system 10. A mutual connection condition of each item of hardware (for example, a CPU, a memory, and a module A) in the verification subject system 10, and implementation information of each item of hardware, may be included in the system model. Then, a power consumption and processing performance when executing a simulation of the verification subject system 10 are provided as estimate values of the verification subject system 10.
Also, heretofore, a degree of detail of a register transfer level (RTL) description level or greater is required for the implementation information of each item of hardware. However, a simulation with implementation information of a transfer level (TL) description level, with a degree of detail lower than that of the RTL, has also become possible. Furthermore, a simulation with a coordinated simulation (Co-SIM) is possible, even in the case of implementation information in which the RTL description and TL description are mixed. (JP-T-2005-525660).
To execute a simulation of the verification subject system, it is sufficient to prepare implementation information of each item of hardware. Among the items of hardware, it is comparatively easy to prepare implementation information for a highly versatile CPU, memory, or the like, as there are many opportunities for design, and it may also be possible to divert implementation information designed for another system.
An item of hardware such as the module A of the verification subject system 10, which is newly designed and is intended for a highly specialized process, may need longer to prepare the implementation information in comparison with the CPU and memory. When executing a simulation of the whole system, a simulation scenario such as the one below is provided:
“Scenario example” CPU (write transaction to module A)                WriteAddress(address)//write request to module A        WriteData(a)//transmit write data a        WaitAck//wait for response from module A        . . . (the following omitted) module A (receives write request from CPU)        GetAddress(address)//wait for address request        . . . (the following omitted)        
As in the above scenario example, in order for the CPU to carry out an appropriate operation in accordance with the scenario, it has to receive a response from the module A. That is, an implementation of all of the hardware in the verification subject system 10, including the module A, is essential for a simulation of the whole of the system. Consequently, in the event that the development of the implementation information of any item of hardware is delayed, the delayed development process becomes a bottleneck when executing a simulation of the whole of the system.
Furthermore, at the system design place, the kind of situation also occurs wherein various kinds of specification, such as those of a communication protocol, are changed at short notice after the implementation information of each item of hardware is prepared. FIG. 2 illustrates a problem accompanying a change in the protocol of the verification subject system. The verification subject system (existing system) 10, designed based on Advanced High-performance Bus (AHB) specifications, is represented on the left side of FIG. 2. Then, an updated system 20, in which the communication protocol is changed to Advanced eXtensible Interface (AXI) specifications, is represented on the right side of FIG. 2. With the updated system 20, it is taken that implementation information to which the AXI specifications are applied is prepared for the highly versatile items of hardware such as the CPU and memory, excluding the module A.
Also, an operation of the module A when the module A is accessed from the CPU is illustrated under each system. In the case of the updated system 20, the module A, based on the AXI specifications, has to newly output a response 21 (Response 1) in response to an access signal (WriteAddress) from the CPU. Actually, the module A being unable to output the response 21 because it has not been changed to the AXI specifications, the simulation in the updated system 20 experiences a breakdown.
Countermeasures have been discussed for the problem of eliminating the trouble with the simulation accompanying the specifications change with which the module implementation information does not keep pace. For example, in an e event that the implementation information of one portion of the hardware in the verification subject system 10 does not keep pace, an empty pseudo model which does not include implementation information is connected in place of the module A, in order to execute an early simulation of the whole of the system.
Conventionally, in the event that the specifications are changed as in FIG. 2, a bridge for converting the module A communication protocol is prepared. FIG. 3 illustrates an exemplary of a protocol conversion using a bridge insertion. As in FIG. 3, by connecting a bridge between the bus with the AXI specifications and the module A, a simulation of the whole of the updated system 20 is possible without preparing a module A with the AXI specifications.